バグトラッキングシステム（以降、BTS）のチケットデータには様々な情報が記録されており品質分析に使わない手はありません。バグチケットの分析は個々のチケットに対する定性分析を行うことが多いですが、ODC分析のようにクロス集計を用いる方法もあります。ODC分析にはODC分析用のタグが必要ですが、ここでは基本的なバグチケットにある情報（項目）を用いた可視化の方法を探って行きます。
　

なお、本ページではR version 3.4.4 (2018-03-15)の標準パッケージ以外に以下の追加パッケージを用いています。
　

Package Version Description
tidyverse 1.2.1 Easily Install and Load the ‘Tidyverse’

　
また、本ページでは以下のデータセットを用いています。
　

Dataset Package Version Description
redmine N/A N/A Redmine Issues

　

バグチケットはRedmine が公開しているRedmine自体のバグチケットを用います。RedmineはGPL v2ライセンスの下で提供されているオープンソースのプロジェクト管理ソフトウェアです。上の表の場所でチケットを公開していますが、一度に50レコードまでしかダウンロードできないため事前にこちらで取得したレコードをデータフレーム形式にまとめたものを利用します。

　

チケット情報のインポート

前述のように今回は事前に整理したデータフレーム形式のチケット情報を用いますが、実際にはBTSのAPI機能やBTSのDBMSから直接取得することをおすゝめします。直接取得できない場合は、CSVファイルへエクスポートするなどの方法を取ってください。
　

チケットの項目

今回用いるRedmineのバグチケットの項目を簡単に説明してます。基本的な項目のみが用意されています。実際は因子型になっている項目をここでは文字型として扱っている点に注意してください。
　 　

項目 概要 データ型
# 識別番号（Primary Key） 整数型
プロジェクト 属するプロジェクト 文字型（因子型）
トラッカー 大分類 文字型（因子型）
親チケット 親子関係を定義したい場合に用いる 文字型
ステータス 対応状況 文字型（因子型）
優先度 対応優先度 文字型（因子型）
題名 タイトル 文字型
作成者 作成者 文字型（因子型）
担当者 対応担当者 文字型（因子型）
更新日 更新日時 日時型（POSIXct）
カテゴリ 分類（任意に利用設定できる） 文字型（因子型）
対象バージョン チケット対処したバージョン 文字型
開始日 対応を開始した日 日付型
期日 対応予定期間 日付型
予定工数 対応予定工数 数値型
進捗率 対応の進捗率 数値型（%表記）
作成日 作成日時 日時型（POSIXct）
終了日 対応完了日時 日時型（POSIXct）
関連するチケット 関係するチケット番号 文字型
Resolution 解決結果（非標準） 文字型（因子型）
Affected version 影響のあるバージョン 文字型
説明 詳細 文字型

　

チケットデータ

実際のデータは以下のような四千レコード弱のデータです。
　

(redmine <- "./data/redmine.csv" %>% 
  readr::read_csv(local = locale(encoding = "UTF-8")))

　

分析のための前処理

分析に必要な前処理を行っておきます。作成日と終了日のデータは実際は日時データになっていますので日データに変換して、必要な項目のみを抽出しておきます。
　

(x <- redmine %>% 
  dplyr::select(no = `#`, tracker = `トラッカー`, status = `ステータス`,
                priority = `優先度`, category = `カテゴリ`,
                version = `対象バージョン`, affected = `Affected version`, 
                open = `作成日`, close = `終了日`, subject = `題名`,
                assignee = `担当者`) %>% 
  dplyr::mutate(open = lubridate::date(open), close = lubridate::date(close)))

　

チケットの分析

　

データの確認

はじめにデータを確認します。トラッカー（チケットの分類）のステータス（対応状況）を確認するためにクロス集計をしてみます。
　

x %>% 
  dplyr::group_by(tracker, status) %>% 
  dplyr::summarise(n = n()) %>% 
  tidyr::spread(key = tracker, value = n)

　
Defectチケットで約75%、Patchチケットで約80%がクローズしていることが分かります。以降、Closedなチケットを除くオープンチケットに対してクロス集計を行います。
トラッカーごとの優先度は
　

x %>% 
  dplyr::filter(status != "Closed") %>% 
  dplyr::group_by(tracker, priority) %>% 
  dplyr::summarise(n = n()) %>% 
  tidyr::spread(key = tracker, value = n)

　
となっており、優先度ごとの状態は

x %>% 
  dplyr::filter(status != "Closed") %>% 
  dplyr::group_by(priority, status) %>% 
  dplyr::summarise(n = n()) %>% 
  tidyr::spread(key = priority, value = n)

　
です。緊急の対応を要するチケットの９割の進捗が芳しくないことが分かります。また、優先度があまり高くないチケットもNeeds feedback状態であることから対応の整理が必要なことが推測できます。

緊急の対応を要する対応に急を要するチケットは以下の通りです。
　

x %>% 
  dplyr::filter(status != "Closed") %>% 
  dplyr::filter(priority == "Urgent") %>% 
  dplyr::select(no, tracker, status, subject, assignee)

　
このように緊急対応を要する案件でありながら担当者がアサインされていないことが分かります。次に対応優先度の高いオープンチケットは以下の通りです。
　

x %>% 
  dplyr::filter(priority == "High" & status != "Closed") %>% 
  dplyr::select(no, tracker, status, subject, assignee)

　
こちらも同様に担当者がアサインされているチケットの方が圧倒的に少ない状況です。では、担当者の割当状況を確認してみます。
　

x %>% 
  dplyr::filter(status != "Closed") %>% 
  dplyr::group_by(priority, assignee) %>% 
  dplyr::summarise(n = n()) %>% 
  tidyr::spread(key = priority, value = n)

　
この担当状況を元に担当者が割り当てられていないチケットに担当者をどのように割り当てるかを考えることができます。
では各カテゴリ（分類）における対応優先がどのようになっているかも確認しておきます。
　

x %>% 
  dplyr::filter(status != "Closed") %>% 
  dplyr::group_by(priority, category) %>% 
  dplyr::summarise(n = n()) %>% 
  tidyr::spread(key = priority, value = n)

このように特定のカテゴリにバグが集中していないことは分かります。

時系列の変化